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ABSTRACT 



A DCE RPC mechanism normally uses a TCP/IP-based 
transport service to enable client machines to make remote 
procedure calls to server machines in a distributed comput- 
ing environment. NETBIOS protocol support for the RPC 
mechanism is provided by using NETBIOS application 
names similar to TCP/IP conventions and through use of 
connection-oriented or connection-less NETBIOS protocol 
sequences. In particular, NETBIOS names are used as 
though they include a fixed portion representing a machine, 
and a dynamic portion representing an application on that 
machine. New functions arc provided to use NETBIOS 
names in place of TCP/IP addresses and these NETBIOS 
names are then used via the sockets API, leaving RPC's use 
of the sockets API unchanged. 

20 Claims, 4 Drawing Sheets 
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NETBIOS PROTOCOL SUPPORT FOR A DCE (i.e., network layer) protocol sequences of the Internet 

RPC MECHANISM Network Address Family (AF_INET) to open the sockets. 

Local area network managers are becoming more varied, 
T1ECHNICAL FIELD consisting of different LAN technologies, multiple vendors 

The present invention relates generally to computer com- ^ multiple adapters. There is also a higher performance 
munications and, more particularly, to adding NETBIOS requirement and a greater need for an increased number of 
protocol support in a known DCE RPC implementation. connections to servers and to network management. In the 

prior art, it is also known to support a number of protocol 
BACKGROUND OF THE INVENTION "stacks" on a particular machine to enable support of 

A 1 1 . 1 /I A Kr\ -J J- * * J multiple network protocols. Thus, for example, a machine 

A local area network (LAN) provides a distnbu ted com- ^ ^ Kmi-oi/^c /^tt-t i r» • i *fr\ * * 

, . V J- 4 L . J may support a NETBIOS (NETwork Basic Input/Output 

putmg environment in which users can access distributed ^ , . /™ . . ^ . Tr. . 

A r u- 1 * System) stack, a TCP/IP (Transmission Control Protocol/ 

resources and process apphcations on multiple computers. , . : ^ 1^ ^ i j x • / i_ r^vr* 

KT * 1 , ..'^ . J . ^. 11 J Internet Protocol) stack, and other stacks (such as SNA, 

Network commumcatioos are earned out usmg so-called r^cT/r^o j i i \ ^/-.r./tr» • i j i- 

communication orotocols. Bv c«nvenUon. communication )• ™^ TV^nu^rju 

architectures in "a local area network arc typically charac- " P«>6;'^«"?g '^"f « l^y^' (which was 

terized as conforming to a seven layer model in the follow- ^J^^fli ''"^ availab e from BM), for converung 

, i. • 1 1 1 • 1 r 1 1 * 1 NETBIOS programming interface calls to sockets, 

mg hierarchy: physical layer, logical hnk layer, network " ^ 

layer, transport layer, session layer, presentation layer and ^ companies move more of their applications to the 

application layer. The physical layer comprises the actual chcnt/seiver environment, they desire to access servers from 

physical devices and medium used to transmit information. hundredsof computers, some of which use TCP/IP and some 

The logical link layer frames data packets and controls of which use NETBIOS. As noted above, current DCE RPC 

physical layer data flow, insuring delivery of data regardless implementations (such as in 0Sy2) use a sockets API that 

of the actual physical medium. The networit layer addresses supports TCP/IP addressing and protocols. Machines mn- 

and routes data packets. It creates and maintains a route in 25 NETBIOS do not have TCP/IP capability and thus are 

the network between a source node and a destination node. ^^^^ to take advantage of DCE RPC services. While use 

The transport layer creates a transport pipeline between multiple protocol stacks is a possible solution, system 

nodes and manages the network layer connections. The administrators gencraUy do not want to administer a TCP/IP 

session layer typically provides remote procedure call (RPC) network as well as a NETBIOS network, 

support, maintains the integrity of the connection between 30 It would therefore be desirable to add NETBIOS protocol 

nodes and controls data exchange. The presentation layer support to an existing TCP/IP-based DCE RPC mechanism, 
encodes and decodes data and provides transparency 

between nodes. Finally, the application layer provides the ^^^^^ SUMMARY OF THE INVENTION 

interface to end-user processes and provides standardized u is thus a primary object of the present invention to 

services to apphcations. 35 support the NETBIOS protocol in DCE RPC. 

The seven layer model has many variations depending on jt is a more general object of the invention to enable a 
the particular network architecture. Thus, for example, in a NETBIOS-based client to access and use DCE services in a 
network architecture based on the TCP/IP (Transmission network without requiring that the network be administered 
Control Protocol/Internet Protocol) interface running IBM under TCP/IP Preferably, the addressing scheme and pro- 
RISC System/6000® computer workstations under the AIX 40 tocol sequences are NETBIOS-based, such that there is no 
Operating System, there is another layer, called the socket need for a TCP/IP protocol stack in the cUent or use of 
layer, that sits between the session and transport layers. The TCP/IP protocol sequences on the network, 
socket layer creates so-caUed "sockets" which are logical ^ ^^^^^j^^^ .^^^^^^^ ^ ^^^^^^^^ ^^^^ 
constmcts analogous to physical ports. In Oiis architecture, nE^IOS protocol support in DCE RPC without requiring 
he RPC mechanism is not just supported in the session 45 changes to RPC application programming interfaces 
layer, but akomcludesftinctionalUy of the sc^^^ ^^^.^y "native" NETBIOS, the particular addressing 

known RPC mechanism useful m distributed computmg tr.„^^ xtt7tt3ioc u^^^a 

. . , . - , ■ t 1 . . scheme and protocol sequences are NEl BIOS-based, 

environments (DCE) includes software code provided by the . u- ui . kti-t^t«-.o i. j 

Open Systems Foundation (OSF). , another object to enable current NETBIOS-based 

-nt. /^eni^r-non^ u - • j m . ^AN scrvcr systems to upgrade without havmg to add 

11,0 OSF DCE RPC mechanism is used convent. onally o 50 tcp/|P protocol support or to use a TCP/IP proto^l stack, 

manage communication between a "client and a "server^ in o.n . r ^ • • • 

a distributed computing environment, with the client . Still another more general object of the invention is to 

requesUng a service from a server using a remote procedure ^'""^^^y "TAc^^''*'°" ?^ "l^ot? n^^^ 

call (RPC). A "cUent" refers to a network participant that is "^^'^^^S NETBIOS protocol support for DCE RPC without 

requesting a service accessible somewhere within the com- 55 J>?q^^nng administration of a TCP/IP protocol support and 
puling environment. A "server" provides the requested ser- ^ ^^'^^ addresses. 

vice to a client. With the OSF DCE RPC mechanism, each ^et another object of the invention is to enable DCE RPC 
chent process (e.g., a process running on a client machine) configure and manage NETBIOS naming conventions, 

has an associated socket created by the socket layer. Each R is another object of the invention is to eliminate TCP/IP 

server process likewise is associated with a socket. In 60 address administration in a DCE implementation using 
response to an RPC, a call directory service returns a data NETBIOS. 

structure, called a "binding handle," specifying the location Further, it is another more specific object of the invention 
of the server process as a network address and the port to implement "native" NETBIOS in DCE with a minimum 
number where the server process is running. The binding amount of NETBIOS name administration. NETBIOS host- 
handle is then used by the RPC mechanism to define a 65 names are preferably obtained automatically from a Multi- 
communication path between the client process and the protocol Transport Networking Service (MPTS) or from the 
server process. The path is defined typically using ip -based RPC mechanism. 
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These and other objects of the inveation are achieved in comprising a common cabling system 12 to whidi a plxiral- 

a distributed computing environment wherein client ity of workstations 14, 16 and 18 arc connected. A local area 

machines normally issue remote procedure calls (RPC's) to network provides a distributed computing environment in 

server machines over a network using a transport mecha- which users can access distributed resources and process 

nism specified by an application programming interface 5 applications on multiple computers. Network communica- 

(API), a first addressing scheme and a first protocol. A tions are carried out using so-called communication proto- 

preferred method of the invention then begins by configur- cols. It is understood by those of ordinary skill in the art that 

ing a set of application addresses in accordance with a the workstations are equipped with a physical adapter card 

second addressing scheme associated with a second pro to- and that the cabling system may have a bus or ring topology 

col. In response to an RPC issued by a client machine, an and be implemented as a coaxial cable, twisted pair, fiber 

application address from the set of application addresses is optic cable or any other supported communications media, 

obtained. Thereafter, the application programming interface Moreover, the several workstations need not be physically 

of the transport mechanism and the second protocol are used identical and may have diflfering features, 

to execute the RPC to a server machine identified by the Each of the workstations is a computer. For example, each 

application address. computer may be an IBM® or IBM-compatible computer 

In the preferred embodiment, the API of the transport running under the OS/2® operating system. For more infor- 

mechanism is sockets and the first protocol is TCP/IP, and mation on the OS/2® operating system, the reader is 

the second protocol is NETBIOS. The RPC may be executed directed to OS/2® 2.0 Technical Library, Programming 

using a NETBIOS connection-oriented protocol sequence, Guide Volumes 1-3 Version 2.00, Order Nos. 10G6261, 

or by using a NETBIOS connection-less protocol sequence, 20 10G6495 and 10G6494. While the invention will be 

The step of configuring the set of application addresses described in terms of this hardware and software, one skilled 

includesthestepsof generating a hostname to represent each in the art will recognize that other operating systems and 

server machine in the network that supports NETBIOS hardware can be supported without tmdue experimentation, 

applications, and assigning the hostname to a first fixed Also resident on the computer system may be a network 

portion of an application address. The hostname may be 25 operating system software for controlling LAN communi- 

automatically generated by a multiprotocol transport cations. Each of the workstations may function as a client or 

service, or it may be generated in some other fashion. In ascrvcr. A particular client and server communicate over the 

addition to the first fixed portion, the application address has network during a state referred to as a "session." 

a second variable portion, and the step of configuring the set FIG. 2 shows a block diagram of the components of one 

of application addresses also generates a port number for 30 of the computers shown in FIG. 1. As will be discussed 

each NETBIOS application supported on the server below, is wiU be assumed that the computer supports a 

machine. The port number may be generated on an NETBIOS-bascd transport mechanism and that it is desired 

as-needed basis by an endpoint mapper to resolve dynamic to enhance this computer to enable it to carry out DCE RPC 

endpoints. functionality without conventional TCP/IP constraints (e.g., 

The foregoing has outlined some of the more pertinent 35 inclusion of a dedicated TCP/IP protocol stack, use of 

objects of the present invention. These objects should be TCP/IP protocol sequences on the wire, etc). The system 

construed to be merely illustrative of some of the more unit 21 includes a system bus or plurality of system buses 31 

prominent features and applications of the invention. Many to which various components arc coupled and by which 

other beneficial results can be attained by applying the communication between the variotis components is accom- 

disclosed invention in a different manner or modifying the 40 plished. The microprocessor 32 is connected to the system 

invention as will be described. Accordingly, other objects bus 31 and is supported by read only memory (ROM) 33 and 

and a fuller understanding of the invention may be had by random access memory (RAM) 34 also connected to system 

referring to the following Detailed Description of the pre- bus 31. A microprocessor in the IBM series of computers is 

f erred embodiment. one of the Intel family of microprocessors including the x86 

BRIEF DESCRIPTION OF TOE DRAWINGS or Pentium microprocessors. However, as noted above, otoer 

microprocessors mcluding, but not limited to, Motorola s 

For a more complete understanding of the present inven- family of microprocessors such as the 68000, 68020 or the 

tion and the advantages thereof, reference should be made to 68030 microprocessors and various RISC microprocessors 

the following Detailed Description taken in connection with manufactured by IBM, Hewlett Packard, Sun, Intel, 

the accompanying drawings in which: Motorola and others may be used in the specific computer. 

FIG. 1 illustrates a computer network in which the present The ROM 33 contains among other code the Basic 

invention is implemented; and Input-Output system (BIOS) which controls basic hardware 

HG. 2 illustrates a representative personal computer or operations such as the interaction and the disk drives and the 

"workstation" of FIG. 1 which forms part of the LAN; keyboard. The RAM 34 is the main memory into which the 

FIG. 3 is a block diagram of a representative LAN ss operating system (OS) 60 and application programs are 

Network Operating System (NOS) and transport architcc- loaded. The memory management chip 35 is connected to 

ture for the computer of FIG. 2; the system bus 31 and controls direct memory access 

FIG. 4 is a block diagram of a known DCE RPC mecha- operations including, passing data between the RAM 34 and 

nism in which the present invention is implemented; hard disk drive 36 and floppy disk drive 37. The CD ROM 

FIG. 5 is a flowchart of a NETBIOS connection-oriented 60 42, also coupled to the system bus 31, is used to store a large 

socket session according to the present invention; and amount of data, e.g., a multimedia program or large data- 

HG. 6 is a flowchart of a NETBIOS connection-less 

socket session according to the present invention. ^^o connected to this system bus 31 are various I/O 

controllers: the keyboard controller 38, the mouse controller 

DETAILED DESCRIPTION 39^ ^j^^ ^^^eo conUroUer 40, and the audio controller 41. The 

Referring now to the drawings, and more particularly keyboard controller 38 provides the hardware interface for 

FIG. 1, there is shown a typical local area network (LAN) 10 the keyboard 22, the mouse controller 39 provides the 
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hardware interface for the mouse 23, the video controller 40 protocol networking. MPTS enables applications programs 

is the hardware interface for the display 24, and the audio designed to operate over one transport protocol (e.g., SNA, 

controller 41 is the hardware interface for the speakers 25a NETBIOS or TCP/IP) to operate over different transport 

and 25^. One or more I/O controllers 50, such as a Token networks. It is designed to separate the type of addressing 

Ring Adapter, and Ethernet Adapter, a PC-Net Adapter, and 5 and the API used by the application from the protocol used 

so on, enables communications over the network 56 to other at the transport layer. MPTS is described in U.S. Pat. No. 

similarly configured data processing systems. 5,224,098, which is incorporated herein by reference. 

RAM 34 also supports a Network Operating System The present invention implements native NETBIOS in a 

(NOS) 51 and an associated transport mechanism 53 which known DCE RPC mechanism. By way of brief background, 

together control LAN communications. A protocol stack -^q FIG, 4 illustrates the OSF DCE RPC mechanism with the 

support routine 55 is also supported for enhancing the DCE client 61 on one side of the system boundary and the 

number of server sessions that may be supported by the DCE server 62 located on the other side. Client and server 

machine, as will be described in more detail below, stub files 64fl and 64b include RPC routines for message 

FIG. 3 represents a block diagram of the Network Oper- handling, including the marshaling and unmarshaUing of 

ating System (NOS) and LAN transport mechanism running ^5 data into messages that are sent or received. More 

in the workstation of FIG. 2. The TCP/IP protocol stack is specifically, the client stub 64a is the code for an RPC 

shown in dotted lines because in this invention (as discussed interface that is linked with and called by the client apph- 

above) the stack is not required (or may not be used if cation code 66fl. In addition to data marshaling, a client stub 

present). Conceptually, all of the components (except the is used to call the RPC runtime 69a to perform RPC's and, 

physical cards) are supported in software running in the 20 optionally, to manage bindings. The server stub 64b is the 

RAM 34 of the computer. As seen in the left portion of the calling code for an RPC interface that is linked with server 

figure, by convention communication architectures in a local application code 66fc containing one or more sets of remote 

area network are typically characterized as confonning to a procedures that implement the interface. Both the client and 

seven layer model in the following hierarchy: physical layer, server include operating system libraries (68a and 6Sb) that 

logical or "data" link layer, network layer, transport layer, 25 ^1*^^° routines for handling socket calls, file manipulation 

and the upper layers comprising session layer, presentation functions, standard I/O functions, memory management, and 

layer and application layer. The physical layer comprises the exception handling functions. The client and server systems 

actual physical devices and medium used to transmit also include a number of DCE servers (70a and 706) for 

information, and it consists of physical adapter cards. The executing procedures for a user application program. In 

logical or data link layer fi-ames data packets and controls 30 particular, the client DCE servers 70a normally perform 

physical layer data flow, insuring delivery of data regardless ^ocal services for client application programs such as nam- 

of the actual physical medium. The network layer addresses ing or directory services, security services and time services, 

and routes data packets. It creates and maintains a route in Th^ DCE servers 10b may perform remote services for 

the network between a source node and a destination node client application programs such as print services, file ser- 

of the network. The transport layer creates a transport 35 vices and the like. 

pipeline between nodes and manages the network layer Typically, DCE is layered on top of its local operating 
connections. The session layer may provide remote procc- system and networking software (not shown). In this 
dure call (RPC) support, maintains the integrity of the example, DCE is layered over a transport level service such 
connection between nodes and controls data exchange. The as UDP/IP transport service (72a and 726), which is 
presentation layer encodes and decodes data and provides 40 accessed through a transport interface such as sockets (74a 
transparency between nodes. Finally, the apphcation layer and 74b). The implementation of the DCE system shown is 
provides the interface to end-user processes and provides dependent upon the Internet Protocol (IP), socket network- 
standardized services to applications. ing services and operating libraries. 

The seven layer model has many variations depending on When the DCE client's application code 66a makes a 

the particular network architecture. The transport mecha- 45 remote procedure call, the code passes input arguments to 

nism conforms to a Network Driver Interface Specification the stub 64a for the called RPC interface (i.e. the RPC stub 

(NDIS) which provides a standardized medium access con- routines). The client's stub 64a marshals the input argu- 

trol interface for network adapter drivers 57 (identified as ments and dispatches the call to the chent DCE RPC runtime 

Token Ring, Ethernet, PC-Net, etc.) and protocol drivers 59 69a. The client's DCE RPC runtime transmits the input 

located within the protocol stacks. NDIS is described in 50 arguments over the communications network via the socket 

detail in the LAN Manager Network Driver Interface interface, socket interface layer and UDP/IP transport 

Specification, published jointly by 3COM and Microsoft. service) to the server's DCE RPC runtime 69b. 

NDIS has become an industry standard for network adapters The server's DCE RPC runtime 69b dispatches the call to 

and LAN software to communicate with each other. The the server stub 64b for the called RPC interface. The server 

NDIS layer separates protocol handling from hardware ss stub then uses its copy of the RPC interface to unmarshall 

manipulation by defining functions that protocol drivers and the input arguments and pass them to the called remote 

network adapter drivers must provide to each other. NDIS procedure, which is one of the DCE servers 70^. The 

defines specifications for network protocol drivers, adapter procedure executes and returns any results to the server's 

drivers, an interface between network protocol drivers and stub 646, which then marshalls the results and passes them 

adapter drivers and a binding process to link the protocol and 60 to the server's DCE RPC runtime 69b. The server's RPC 

adapter drivers. The figure also shows that the mechanism runtime transmits the results over the network to the client's 

supports the IEEE 802.2 specification, which is described in DCE RPC runtime 69a, which then dispatches the results to 

more detail in International Standard (ISO) 8802-2 (1989). the client's stub 64a. The stub uses its copy of the RPC 

As also seen in FIG. 3, the transport mechanism includes interface to unmarshall the output arguments and to pass 

a Multiprotocol Transport Networking Service (MPTS) 51. 65 them to the calling application. , 

Multiprotocol Networking (MPTN) is an IBM architecture In DCE, before any client program can call a server I 

accepted by the X/Open Foundation that supports mixed function, it must first establish a binding to the server. This | 



01/20/2004, EAST Version: 1.4.1 



us 6,366,958 Bl 



is accomplished by acquiring a binding handle from the 
DCE RPC runtime component. A binding handle contains 
information about the communications protocol that a server 
uses, the address that the server is listening on and, 
optionally, the enrip nint that th e server is listening o n, and 
other information (e.g., an RPC protocol version number). A 
binding handle may be obtained by string binding or from a 
naming service. String binding is used to convert a string 
representation of the binding handle to the actual handle; 
alternatively, a DCE naming service is used to look up 
servers in the namespace and return appropriate binding 
handles. The name space is a complete set of CeU Directory 
Service (CDS) names that one or more servers look up, 
manage and share. Binding bandies returned from the name 
space tisuaily only contain the netv/ork address of the node 
providing a given service. The network address is an address 
that identifies a specific host on the network. The actual 
"endpoint" at that node, which is the address of a specific 
server instance on the host, is usually not registered in the 
cell directory service because these entries change fre- 
quently. The DCE system supplies a server called rpcd that 
runs on a well-known port (#135) on every server machine. 
A server normally binds an endpoint and registers it with the 
rpcd daemon. When a client detects that it does not have an 
endpoint to bind to on the remote system, it contacts the 
endpoint mapper on that node to look up the server's 
endpoint. S^<d<!^ 

When a server starts up it gets an endpoint assigned to it 
by caUing an RPC_USE_API. Then, the server calls RPC_ 
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As can be seen, the type of addressing used and the protocol 
actually used to communicate on the LAN may be dififerent. 
If the address family is the same as the protocol used, it is 
referred to as a "native" configuration. If they arc di£ferent, 
it is called "non-native.^' MPTS for OS/2 provides both 
non-native INET addressing over NETBIOS, as well as 
native NETBIOS using the sockets API. 

According to the present invention, native NETBIOS is 
implemented in DCE (e.g., OS/2 DCE). Generally, this is 
achieved as follows. When using native NETBIOS, the 



_ _ _ application (RPC in this case) continues to use the sockets 

EP_REGISTER to caU the endpoint mapper and Kst its 3° AF IILe. call such as "socket V^ind^^ and ^'c^nne<) . When 
endpoint in the endpoint map. Next, the server calls RPC_ ""'^ " ' ' 

NS„BINDING_EXPORT to put its IP address in the 
namespace so that its address can be obtained by clients. 
Client startup typically involves calling RPC_NS_ 



IMPORT_BINDING to get a binding from the namespace. 
This binding contains an IP address but no endpoint. Then, 
the client calls RPC_EP_RESOLVE_BINDING, which 
contacts the endpoint mapper at the server machine to get the 
actual endpoint for the server. The client has a full binding 
^and is then ready to call the server. 

If the server has a well- known endpoint, it can export a 
full binding to the namespace . In this case, the client get s 
bo ^ IP fldflrpss and porttf ffS m tne namesp l^ More 
typically, the server will export a partial binding to the 
namespace and register its port# (endpoint) with the end- 
point mapper. In iis way, the client can get the protocol 
sequence and the IP address from the namespace, and the 
porl# from the endpoint mapper. If the client knows what 
machine the server is on, and if it knows what port# the 
server is using, it does not need to use either the namespace 
or the endpoint map. This information can be hardcoded in 
the client, or can be command line parameters that the user 
supplies when starting the client. The client can create its 
own binding for the server by creating a string binding from 
the individual pieces (protocol sequence, host, and port^, 
and y converting the string binding to a normal binding. 

The above background has been provided to provide the 
context of the present invention in which native NETBIOS 
is implemented in a known DCE RPC mechanism. The 
concept of "native" NETBIOS is now explained. In 
particular, it is known that three (3) components are neces- 
sary to uniquely specify a transport mechanism protocol 
stack: (a) an application programming interface (API), (b) an 
addressing scheme, and (c) a protocol. The following table 
sets forth various communication protocols of a known OS/2 
architecture: 
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RPC opens a socket, it teUs MPTS 61 (of FIG. 3) it wants 
the addressing domain to be NETBIOS. When the RPC 
issues a bind, it then uses a NETBIOS name. When the RPC 
performs a connect, it includes a NETBIOS socket address 
with the NETBIOS name of the RPC server to which it 
desires to connect. The invention provides this NETBIOS 
name management facility, either by having the names 
generated by RPC and passed in the bind to MPTS or, 
preferably, by having MPTS create unique names as a result 
of a bind call with no name. In addition to this NETBIOS 
name support, the invention adds connection-oriented and 
connectionless NETBIOS protocol support (since RPC sup- 
ports both), and it provides a set of network address family- 
specific routines for NETBIOS support. These specific fea- 
tures of the inventive scheme can now be discussed. 

In NETBIOS, applications are known by NETBIOS 
names, which are fixed length 16 byte strings, with each 
application in a machine having a unique name. Also, there 
is no domain name server in NETBIOS. On each machine, 
NETBIOS maintains a names table for all applications on 
that machine. When an application starts, NETBIOS checks 
to see that that name is not already is use at another machine 
by broadcasting name queries on the network. If the name is 
not already in use, it is added to a names table on the local 
adapter. 

To the contrary, with TCP/IP addressing, all application 
addresses within a machine have a common part (the IP 
address) and a unique part (the port number), and TCP/IP 
uses dynamic and well-known endpoints. As previously 
discussed, a dynamic endpoint means that the bind does not 
contain a port number, so one must be assigned by MPTS; 
a well-known endpoint means that the application wants to 
use a specific port number and thus passes this port niunber 
to MPTS in a bind. With NETBIOS, each application's 
name may be completely different. A N ETBIOS bind qd Iv 
bin ds the NETBIOS s ocket t o one physical adapter whil e a 
TCP/IP bind binds the sockeHo all adapters. 
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To carry out an RPC, a DCE clieat needs to know the IP 
address of the server, the port # of the server, and the 
protocol to use (udp or tcp protocol sequence). TCP/IP 
addressing involves a 4 byte IP address and a 2 byte port 
number. NETBIOS addressing (as noted above) uses a NB 
name, which is always a 16 byte character string. According 
to the invention, NETBIOS names arc configured to con- 
form to the TCP/IP addressing scheme, i.e. to include a fixed 
portion, representing the machine on which an application is 
located, and a changing portion, representing the application 
on that machine. Preferably, all NETBIOS names are built 
with the first 12 bytes representing that machine and the last 
bytes representing a port number. When a server wants a 
dynamic endpoint, the NETBIOS name is built with the NB 
hostname and an incrementing port number. The server then 
exports the hostname into the namespace and registers the 
port number with rpcd. When the client wants to contact the 
server, it contacts rpcd using a known name, i.e, the NET- 
BIOS hostname, where the server is located, with a port 
#135 (the location of the mapper) appended. When a server 
wants a well-known endpoint, the NETBIOS name is gen- 
erated by appending the endpoint to the configured NET- 
BIOS hostname. 

Although not meant to be limiting, preferably MPTS 
handles the name generation, with the first 12 bytes filled 
either with a user-configured ASCII string. The last 4 bytes 
are filled with an incrementing port #, or a well-known 
endpoint if it is passed to MPTS. 

Thus, according to the preferred embodiment of the 
invention, one NETBIOS name is assigned to represent a 
machine, and all NB names used by DCE in this machine are 
then based off the one name. This name assignment is 
preferably handled by MPTS graphical user interface (GUI) 
so that neither user applications nor OS/2 DCE have to do 
their own name assignments, MPTS handles these names so 
that DCE can easily divide them into a fixed portion (the 
machine name), which DCE can use like the former IP 
address (in TCP/IP), and a changing portion, which DCE can 
use like the port assignment or endpoint (in TCP/IP). 
Preferably, the first 12 bytes are fixed and the last 4 bytes 
vary, although other formats may be used. The 4 byte 
variable portion lets the port number in ASCII go up to 9999, 

When the NETBIOS hostname is configured in MPTS, 
typically it will be padded on the right with ASCII blanks up 
to 12. Normally, the name will be formed of ASCII char- 
acters and no embedded blanks or backslashes are included. 
The trailing blanks will be truncated when the hostname is 
printed in a string binding, and added in when a string 
binding is converted back to an address in a regular binding. 
A binary zero in the first byte means that no hostname is 
present. 

The four bytes of the endpoint are also preferably ASCII 
characters. They are not required to be ASCII numbers, but 
they typically will be such numbers. When a port# is 
dynamically assigned (by MPTS or RPC), it will be 4 ASCII 
digits. If a port# is input from a string binding or a call like 
rpc_server_use_protseq_ep, it will be truncated on the 
left if it is longer than 4 characters, and padded on the left 
with blanks if it is shorter. When converted to a string 
binding, the blanks on the left will be truncated, and they 
will be added back in when it is converted to a regular 
binding. As noted above, preferably no embedded blanks or 
backslashes are allowed. 

Support of native NETBIOS also requires two new pro- 
tocol sequences, referred to herein as ncacrL-nb_stream and 
ncadg_nb_dgram. These protocol sequences arc built using 
the AP^J^JETBIOS NETWORK Address FamUy (NAF) and 
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a socket type of either SOCK_STREAM or SOCK_ 
DGRAM. The socket address uses the data structure 
sockaddr_jib. The design of the RPC runtime Ubrary 
(reference numeral 69 in FIG. 4) is such that the addition of 

5 a new protocol sequence can be accompUshed with very 
little modification to the existing code. This is achieved via 
two means: (1) modular data stmctures, and (2) the use of 
entry point vectors. Modular data structures facilitate the 
effort of adding a new protocol sequence by providing a 
consistent mechanism by which to relate the various com- 
ponents that make up the protocol sequence. The majority of 
the RPC runtime code is common to all protocols, so the use 
of entry point vectors allows protocol specific routines to be 
accessed in-line, via an index into an array of functions. The 

15 protocol id is used as the index into the entry point vector. 
The two new protocol sequences require the addition of new 
routines to handle processing that is specific to that protocol 
sequence. These routines manipulate NETBIOS addresses in 
both the 12 byte hostname/4 byte endpoint form, and in the 

2Q 16 byte NETBIOS name form. 

Some RPC APFs deal with string bindings, which may be 
of the form: 

objuuid@protocol_sequence:hostoame_or_ipaddress 
[port,options]. 

25 For Native NB, string bindings will use this same format, 
with the NB name split between the hostname and port 
fields. For example: 
ncacn_nb_stream:myhostnamexx [1024] 
ncadg_nb_dgram:myhostnamexx [1035]. 

30 Binding information in the namespace, as well as in the 
endpoint map, is kept in a "protocol tower". This is a data 
structure where each piece of data is known as a floor. For 
TCP/IP, floors 3, 4, and 5 contain the protocol id, endpoint, 
and IP address. For NETBIOS, floor 3 contains the protocol 

35 id (CO-connection oriented, or CL-connectionless), floor 4 
contains the whole 16 byte NB name, and floor 5 is NULL. 
When the tower is converted to a binding, an 'addr_has_ 
endpoint' flag in the binding is set depending on whether 
there is a complete NB name or just a partial one. If the last 

40 4 bytes are binary zeros, then the port# has not been set. 
FIG. 5 is a flowchart illustrating a NETBIOS connection- 
oriented socket session implemented according to the teach- 
ings of the present invention. This flowchart shows the 
process flow when the application specifies the ncacn_nb_ 

45 stream protocol sequence. The various functions of the client 
are located on the left portion of the chart, and the functions 
of the server are located on the right portion. At step 80. the 
client creates a stream socket "s" with the sockcts ( ) call 
(which IS an KPC API). The server also creates a stream 

so socket "s" with the sockets call. These steps indicate that the 
chent and server are fixina to open up a connection and thu s 
certain data structures must be setjip . At step 84 (which is 
optional) and at step 86. the client^ foptionally^ and serve r 
' issue a bind call to bind the socket "s" to a local address . 

55 According to the present invention, the local address is the 
name (of the client or server, as the case may be) and is a 
NETBIOS name, preferably generated by the MTPS as 
discussed above. At step 88, the server issues a listens( ) call, 
indicating that it is willing to accept calls. At step 90, it is 

60 assumed that the client issues a connect( ) call that seeks to 
connect socket "s" to a foreign host, which in this case is the 
server. The connect call specifies the destination address by 
the NETBIOS name. The variable portion of the name may 
be obtained through an endpoint mapper if necessary. 

65 At step 92, the server accepts the connection and receives 
a second socket "ns" by issuing an acccpt( ) caU. At this 
point the particular session is opened and the RPC may be 
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carried out. For the server, socket s remains available to Therefore, no diangcs are required to any of the external 

accept new connections and socket ns is dedicated to the RPC APIs. Also, no changes are required lo other DCE 

client. At steps 94 and 96, the client reads and writes data on components in their use of the RPC APIs. However to the 

socket s and the server reads and writes data on socket ns, extent they use sockets API calls directly, or directly 

until all data has been exchanged. The read and write 5 manipulate network addresses, they will be affected, 
operations are carried out using send( ) and receivc( ) calls. 

At step 98, the client closes socket s and ends the session 2.0 External Interfaces 

with a soclose( ) call. The server closes socket ns with the x^e use of NETBIOS is very similar to the use of IP 

soclose( ) caU at step 100. The server may then accept protocols. Many appUcations will not have to change at all 

another connection from a client or close the original socket lo use NETBIOS. If MPTS is configured with NETBIOS 

-s^wilh the socloseO call at step 102. support, the application will automatically use it when 

FIG. 6 illustrates a connection-less socket session when rpc_server_use_aU_protseqs is used. However there are 

the application specifies the ncadgjb_dgram protocol differences in some areas. This section will describe what 

sequence. At step 104, the client creates a datagram socket qqE administrators, users, and appUcation writers need to 

s with the socket( ) call. Likewise, the server creates a 15 know. 

datagram socket s with the socket( ) call at step 106. The ™ . • ^i„j„ i co™.^„^^o MDniTrkc 

* . , . II v.. i ... -.11 J J This mcludes two (2) new protocol sequences, NETBIOS 

Ghent then (opUonaUy) binds die socket to ite local address ^j,,^; ^^^^^ bindings, DCE configuration for 

at step 108 and the server binds the socket to its local nativeNETBIOS.limilaUonsofnativeNETBIOS.directuse 

address at step 110. As noted above, the local address is a * xatttc^ i .Am n n^rrro « r 

KTi-T-oTrxo J J A* . Ill 1- . 11 of MPTS socket API calls, MPTS configuration for native 

NETBIOS address. At step 112, the client optionally con- 20 vrnTrnirio -i -j* a: - * vrcTOTy^o 

, , , • . 1 . . ; . NETBIOS, and providing sufficient NETBIOS resources, 

nects socket s to associate the socket with the server address. « - t^oc t r 

n,- • • J * • 4/ \ II 2.1 DCE Information 

I nis IS carried out using the connect( ) call. The server 211 Protocol Se ences 

optionally associates socket s with the client address using ' ^ ^ , , u- u *l. vti-t- 

,L 11 . . -i^ ^ • • .1 •J 1 There are 2 new protocol sequences which use the NET- 

tne connectf ) call at step 114. The session is then considered m/^o jj r -i r™ 

A.* ii^ j iio*i- 1'. J J J BIOS address family. They are: 

open. At steps 116 and 118, the chent and server send and 25 

receive data on socket s using send( ) and recv( ) calls (if the ncacn_nb_stream 

connect( ) was called in steps 112 and 114). If steps 112 and ncadc_nb__dgram 

114 were omitted (which is preferred), the client and server These protocol sequences may now be used in the same 

use sendto( ) and recvfrom( ) calls (and the binding steps are way that the IP protocol sequences were used before. All 

implemented). At steps 120 and 122, the client and server 30 APIs which deal with protocol sequences will accept the 

end the session with an appropriate close socket call. °cw NETBIOS protocol sequences. The protocol sequence 

A detailed functional description of the native NETBIOS section of the RPC API chapter in the DCE Application 

design implementation is now provided. Programmer's Reference may be reviewed for more infor- 

_ mation. For example, if the application uses the rpc 

FEATORE-ADD tiAHVE NETBIOS TO FULL server_usc_all_p,!otseqs API, then NETBIOS will aut^ 

matically be in the list of protocols registered with the RPC 

1.0 Technical Approach runtime (assuming that NETBIOS is configured in MPTS). 

1.1 Segmenting NETBIOS Names 2.1.2 NETBIOS Addressing and String Bindings 

A preferred solution is to use NB names as though they NETBIOS addressing differs from IP addressing. How- 
had a fixed portion representing the machine, and a changing 40 ever the writer or user of an RPC application usually does 
portion representing the application on that machine. Build ti^^e to be concerned about the sort of addresses that are 
all NB names with the first 12 bytes representing that used by a particular protocol sequence. There are 2 excep- 
machine, and the last 4 bytes representing a porl#. tions. During DCE configuration, the user will have to enter 

Partial bindings can be supported. When a server wants a addressing information. In addition, some RPC APIs use 

dynamic endpoint, the NB name is built with the NB 45 endpoints (rpc_56rver_use_protseq_ep), and others 

hostname and an incrementing port#. The server can export manipulate string bindings. 

the hostname into the namespace, and register the port# with String bindings contain network addresses and endpoints. 

RPCD. When the client wants to contact the server it will If the user needs lo use or look at string bindings, he or she 

contact RPCD using a known name, i.e. the NB hostname needs to understand how NETBIOS addresses are used in 

where the server is located, with a port# of 135 appended. 50 DCE. 

When a server wants a well-known endpoint, the NB ^'^^^ NETBIOS, applications are known by NETBIOS 

name can be generated by appending the endpoint to the names. NETBIOS names are fixed length 16 byte strings, 

configured NB hostname. Each application in a machine has a unique name. 

MPTS handles the name generation. The first 12 bytes are With NETBIOS sockets, a socket address structure was 

filled either with a user-configured ASCII string. The last 4 55 defined for NETBIOS. Here are the differences between the 

bytes are filled with an incrementing porl#, or a well-known socket address structures for each address family. The socket 

endpoint if it is passed to MPTS. address structure for UNIX domain (local) sockets is 

In this way, dealing with NB addressing information fits included for comparison: 

in very well with the structure of DCE. struct sockaddr_nb {/* AF_NETBIOS */ 

1.2 New Protocol Seauences and the RPC API Calls 60 short snb_family; /^unique or multicast*/ 
To use NaUve NETBIOS with DCE, two new protocol short snb_tpc; /* netbios nctid */ 

sequences are defined, ncacn nb_stream, and ncadg^ ^^^^ ^^^^ . 

dgram, for connection-onented and connecUonless NET- , • , vrr^™.^ ' 

BIOS protocols. When using the RPC APIs, these new struct sockaddr^nj/* AF_>ffiTBIOS V 

protocol sequences arc used just like the previous protocol 65 ^^^^ sin_family; /* AF_INET */ 

sequences. When host addresses or endpoints are required, u__short sin__port; /* port #*/ 

the correct portion of the NETBIOS name is supplied. struct in_addr sin_addr; /* IP address */ 
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char siD_zero [8]; /* reserved */ 

struct sockaddr_un {/* AF_NErBIOS */ 

short sun^famQy; /* AF_UNIX */ 

char sun__path [108]; /* path name */ 
NOTE: The netid represents the adapter number to be used. 

Each adapter has a separate names table. So a NETBIOS 
bind only binds that socket to one adapter. In TCP/IP, a bind 
can bind one socket to all adapters (otherwise known as 
network interfaces). 

The NETBIOS protocol itself does not have a concept of 
a machine name, so each application on the same PC could 
have a completely diflferent name. However, to make NET- 
BIOS easy to use in the DCE environment, MPTS allows the 
configuration of a NETBIOS host name (or xises a default for 
it) when using NETBIOS sockets. 

Each 16 byte NETBIOS name is split into a 12 byte host 
name and a byte port name. All names on the same machine 
will have the same first 12 bytes. MPTS will fill these 12 
bytes with a NB host name. 

The host name will be padded with blanks if it is shorter 
than 12 bytes. MPTS will assign a 4 byte port name, just like 
the 4 digit port number it assigns for IP addresses. MPTS 
will only assign numbers, but alpha port names are valid and 
may be used in user-specified port names, such as when 
rpc_server__use_protseq_if is used. For ease of use, NET- 
BIOS names are limited to printable ASCII characters and 
will be uppercased. 

Examples of NETBIOS string bindings are: 

ncacn_Qb_stream:DCESERVERl [1025] 

ncadg_nb_dgram:DCESERVERl [1044] 

You can look at string bindings using DCECP — c end- 
point show. 

You can look at the actual NETBIOS names with the 
NETSTAT — S command. 35 

2.1.3 Configuration of DCE 

DCE configuration will now allow for NETBIOS proto- 
cols to be used and NETBIOS names to be used to specify 
the security and directory servers. 

As well, configuration will prompt for an adapter number 40 
(0-3) to be used for all NETBIOS socket communication. 

When DCE configuration calls for a NETBIOS name, 
enter the NETBIOS host name previously configured via 
MPTS 

Local adapter number is not needed when using IP 
addressing. The IP code can RECEIVE from all adapters if 
all are configured, and the routing table is used to determine 
on which adapter a SEND should be done. However for 
NETBIOS, the adapter number must be specified. The local 
machine's NETBIOS name must be added to the NETBIOS 
names table, of which there is one per adapter. As well, there 
is no routing table to be used to determine which adapter 
should be used on a SEND. Therefore adapter number was 
added to the socket address structure for NETBIOS. DCE 
will only use one adapter at a time for Native NETBIOS, and 
this adapter number may be specified by the user. If no 
adapter number is specified, the default is adapter 0. The 
adapter number is stored in a file. 

2.1.4 Limitations of Native Netbios 
IP can handle user-specified port numbers up to 65535. 

NETBIOS can only use up to 9999 (limited to 4 places), but 
port names do not have to be numeric. Any printable ASCII 
character is allowed, however, some no n -alphanumeric 
characters may cause problems when used in a string 
binding on a command line due to interpretation by the OS/2 
command interpreter. Therefore use of characters other than 
alphanumeric characters is discouraged. 
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2.2 MPTS Information 

2.2.1 Direct Use of MPTS Socket API Calls 

Direct use of MPTS socket API calls may present prob- 
lems when MPTS is configured for NETBIOS sockets only. 
MPTS calls arc divided between protocol- independent and 
protocol dependent calls. Calls such as 'gethostbynamc* and 
'gethostbyaddr* are protocol dependent, and are not avail- 
able when using Native NETBIOS. Sometimes these calls 
are used to get the local machine's address. For Native 
NETBIOS, this can be done by issuing socket, bind, and 
getsocknamc. 

Code which uses the protocol independent API calls will 
also have to be changed to use the NETBIOS address family 
and NETBIOS socket address structure. See the MPTS 
Programmer's Guide for more information. 

2.2.2 Configuration of MPTS 

To use Native NETBIOS sockets, MPTS must be config- 
ured for NETBIOS socket access. TCP/IP socket access may 
be configured as well. See the MPTS Configuration Guide 
for more information. 

2.2.3 Providing Sufficient NETBIOS Resources 
MPTS configuration allows a number of parameters to be 

set for NETBIOS. These parameters can be changed using 
the Edit button on the LAPS configuration panel, or they can 
be changed directly by editing the NETBEUI_nif section of 
the IBMCOM\PROTOCOL.INI file. Hie defaults may 
suffice, but here are some adjustment details. 

2.2.4 Sessions, Commands, and Names 

The following 3 parameters contain the 3 basic resources 
that the NETBEUI device driver must have to provide 
NETBIOS communications services to applications. 

SESSIONS=40 

NCBS«85 

NAMES=21 

NAMES refers to the number of NETBIOS names which 
may be used. NCBs refers to the number of NETBIOS 
control blocks which may be used. The NETBIOS sockets 
device driver uses NCBs as the interface to the NETBIOS 
device driver. SESSIONS refers to the number of 
connection-oriented communications sessions which may be 
active at one time. 

In CONFIG.SYS there are two device drivers, NET- 
BEUI.0S2 and NETBI0S.0S2. NETBEUI owns these 
resources, and they are defined in the NETBEUI seaion in 
PROTOCOL.INI. The statements above show the defaults. 

These resources are shared by Lan Requester and by 
NETBI0S.0S2. Lan Requester does not use NETBI0S.0S2 
but instead interfaces directly with NETBEUI.OS2. Almost 
all other NETBIOS applications use NETBI0S.0S2, includ- 
ing MPTS NETBIOS sockets (NB.SYS). 

When CONFIG.SYS is processed and Lan Requester is 
loaded (when NETWKSTA.200 is loaded), it requests the 
amount of resources specified in IBMLAN.INI. Then when 
NETBI0S.0S2 is loaded, it will get whatever resources arc 
left. This can be seen in the following 3 statements in 
\IBMC0M\LANTRAN.LOG. (LAN^rRAN.LOG is where 
all activity concerning LAPS and MPTS device drivers is 
logged). 

IBM OS/2 NETBIOS 4.0 

Adapter 0 has 140 NCBs, 140 sessions, and 32 names 
available to NETBIOS applications 

NETBIOS 4.0 is loaded and operational 

So MPTS (and other users of NETBIOS) can only get 
whatever is left after Lan Requester has loaded. 

When MPTS NETBIOS sockets (AFNB.SYS) is loaded, 
it does not make a request of resources from NETBIO- 
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S.0S2. However when the first NETBIOS sockets applica- only environment. Some calk addresses and may not work 

tion starts (issues a BIND request), AFNB.SYS will ask in a NETBIOS only environment. Some calls only use code 

NETBI0S.OS2 for resources, and will append the following in TCP32DLL.DLL and do not require the AFINETSYS 

hne in IBMC0M\LANTRAN.LOG so that the user will device driver, and may still work. An example is ntohl ( ). 

know what resources were allocated to it. 5 However other API calls will not work, and the most 

NetBIOS PMM: Using Adapter 0 with 20 NCBs, 20 frequent example is gethostbyname( ^T^i^ 

JO o i- found m applications that assume a TCP/IP environment, 
sessions, and o names. ^ .F^ y *l l j * * fn 
x^rrvr^ u ^ f u ii i o xrAA^cc on Krr-ne Gcthostbyname/gcthostbyaddr may be used to get an IP 
MPTS by default will only reseive 8 NAMES, 20 NCBS, hostname tci use in a string binding, to use diretuy in a 
AND 20 SESSIONS for NETBIOS sockets users. This connect API call, or to use to compare with a host address 
limits RPC to only 8 names. The resources available for 10 that has been obtained elsewhere. This call fails in a NET- 
NETBIOS sockets users like RPC can be increased by BIOS only environment. If a hostname is required, the 
configuring via MPTS panels, which wQl result in changes NETBIOS hostname may be substituted, 
to CONFIG.SYS as follows: Check the .MAP file from the linker to see what protocol 

dependent socket calls are being used. Look for references 

DEVICE«^:\MFTN\PROTOCX)UAFNB.SYS/C:8D/S:80/IN:60 tO tcp32dll. 

T« ;«^r/.oc^ th^ *rY.«,.«t r*cr,,ir^^o o.^o.'ioku t« MTi cvc 2.3.4 Protocol Independent MPTS Socket API Calls 

lo mcrease trie amount or resources available to iSB.oYo, . . t\*nrr>o i . afit m -j .-c j 

, . nDrt^r^oriT iKTi A- 1 A second group of MPTS socket API calls are identified 

mcrea« the parameters in PROTOCOL.INI accordingly^ ^ protocol mdependent. Tliese calls are supported in 

2.2.5 Detecting Failures Due to Insufficient NETBIOS ^ netBIOS only envkonment. However, the parameters to 



the calls will typically have to change. Examples are socket, 



Resources 

NETSTAT -S can be run to see how many NETBIOS 20 ^l^j; connect7send7re7ei^e7Th^?c^^ 
sockets (and NETBIOS names) currently used. If NETBIOS changed to use the NETBIOS address family (AF_NB) and 
names run out, an RPC return code of Ox 16c9a003 the NETBIOS socket address structure. As well as calls such 
(382312451) rpc_s_caiit_bind_socket is provided. as ioctl are in the protocol independent group because they 

It is not as easy to discern when NB.SYS runs out of can be used for both AF_INET on TCPIP and AF_INET on 

NetBIOS sessions or commands. Sometimes the device 25 NETBIOS (non-active). However ioctl is not supported for 
driver cannot report the error in a return code to a socket API AF _J^. 

call, which in turn would be reported with an RPC return 2.3.5 Obtaining the NETBIOS Hostname from MPTS 
code. In this case, NB.SYS will report the error in the To obtain the NETBIOS hostname, open a NETBIOS 
LANTRAN.LOG file, found in the IBMCOM subdirectory. socket with the socket( ) call, bind it with the bind( ) call, and 

This log file should be checked when having problems with 30 ^se getsocknamc( ) to get the socket address structure. 
NETBIOS. The NETBIOS hostname will be in the first 12 bytes of the 

2.3 Chanaes Recuired to run in a NETBIOS only environ- NETBIOS name. 

tnent 2.3.6 Obtaining the NETBIOS Hostname from RPC 

Some DCE apphcations will work without modification ^ ^^^^ f ^^^^ ^° specifically to ajdothej 

in a NETBIOS only environment. Others will not. TTie most 35 ^^f components who require knowledge of the NETBIOS 

common problem has been the use of gethostname or host name, m particdar the sccunty c^^^ 
«u «u Tn-- Ml J- L .t. * configuration. Inis API is bemg defined generally enough so 

gethostbyname. This section wiU discuss changes that may ^^^^ -f ^^^^^J^ l^^^j ,p ^^^^^^ 

be required to some apphcaUons to get them to run success- ^^^^^ NETBIOS addresses (currendy there can only be one). 

- „ J J J ,0 The API will return a new structure called a Detaddir_vector, 

2.3.1 Hardcoded Protocol Sequences 40 so a second API is being defined to free the oetaddr„vector. 
Some DCE applications may have hardcoded IP protocol xhe API is being defined as follows: 

sequences. Naturally these applications will not work in a 
NETBIOS only environment. These must be changed to use 

all or one of the supported protocol sequences, or to allow 

a protocol sequence to be passed in as a parameter. Appli- 45 rpc_jictwork^n8_local_nctaddrs (proucq, ncUiddr_vcctor, 
cations which have hardcoded protocol sequences and end- unsT^ned char t • rotse • 

points coded in their .IDL file for use with rpc_server_ l^"'c!!netaddi_^ctor_t ~ ^™ "netadr_vcctoT 
use_all_protseqs_if will need to add endpoints for uiiBigned32 _*fitatus; 

NETBIOS. ^O''* rpc_jictaddr_vector_fr« (DCtaddr_vcctor, status) 

Scan for any of the protocol sequence strings. 50 ^sf^n''"'^''' ^^a^uT'^'^'^'^' 

2.3.2 String Bindings and Hostnames typcdcf struct 
DCE applications which build their own string bindings { 

using rpc_string_binding__compose have to get the host unsigDcd32 _lcn; 

network address to use as input to the call. These applica- , unsigncd_char_i _ 

- , . . { ipc__netaddr_vcctor_t, *rpc_netaddr_vector_p_t: 

tions frequently use getnostname( ) or getenv( ) to get the 55 

HOSTNAME environment variable. There is no HOST- 
NAME environment variable in a NETBIOS only environ- 1°?^^ ^ ^ protocol sequence string. It is used to specify 
ment. It is also possible some apphcations could be using ^^^^^ address family is being inquired about. No check is 
dce_oL_get_host_name to get a name to use in a string ^^^^ *^ particular protocol sequence is actually 

binding. This call works in a NETBIOS environment, but 60 ^^PPO^ed. That should be determined via rpc_network_^ 
this returns the DCE host name, which may not be the same mq-supported^protseqs. Output is a vector of cither IP 
as either the IP hostname or NETBIOS hostname. See below form, or a NETBIOS hostname, 

for a discussion on how to get the NETBIOS hostname. 3.0 Internal Design Description 

2.3.3 Protocol Dependent MPTS Socket API Calls The majority of the changes to DCE to implement Native 
Agroupof MPTS socket API calls are identified as being 65 NETBIOS are confined to the RPC component. However 

protocol dependent. This means that they are associated with there are changes to security, directory, DCED, and install/ 
the use of IP addresses and may not work in a NETBIOS config as well. 
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3.1 RPC Changes 

The RPC runtime is designed with provision for the 
addition of new protocol sequences. Most of the code is 
address family independent. The functions which arc depen- 
dent on the address family are kept separate, and are called 5 
indirectly via a vector of function pointers known as an entry 
point vector. Each address family has a set of similar 
routines. When the common code needs to call a function 
that is address family dependent, it calls a common function 
which redirects the calls to the function for the current lo 
address family via the entry point vector. The protocol id is 
used as the index into the entry point vector. New protocol 
sequences require the addition of new routines to handle 
processing that is specific to that protocol sequence. 

3.1.1 Addinq NETBIOS to RPC Runtime 15 

(1) Define the rpc_addr structure for NB to use the NB 
address structure sockaddr_nb. Create nbnaf.h. 

(2) Add 2 protocol sequence strings for NB. Add 2 
protocol sequence Ids to go with these protocol 
sequences. Add these to com.h ^ 

(3) Add a NAF id for NB (17). This number was picked 
by MPTS. Add to com.h. See 
mptn\include\sys\50cket.h. 

(4) Add 2 entries to the protocol sequence ID table as 25 
follows: 



rp c_^rotseq._id 


one of the protseq ids we just 




defined 


ip c_p rotocol id 


either ncacn or ncadg 


na£_id 


the Naf id we just defined. (1st pann 




in socket call) 


net_protocoL_id 


protocol id_xins (unspecified) 




(3rd parm in socket call) this is left 




unspecified since there is only one 




protocol (NETBIOS) associated with the 




NETBIOS NAF. 


net_if_jid 


the socket type, stream or dgram. 




(2nd paim in socket call) 


rpc_protscq 


protocol sequence string matching the 




protseq id. 



40 



Hie protocol sequence ID tabic is in comp.c. 

(5) Add entry 17 to the NAF ID table for NB. This is in 
comp.c. 

(6) Add declaration of rpc__nb_init to comnaf.h. This 
routine fills in the NAF function epv and is the only one 
which is referenced by name. 

(7) Create the set of Network Address Family specific 
routines which must be defined for each NAF. The epv 
(vector of pointers) to these routines contains 24 func- 
tion pointers. Create nbnaf.c. (copy from ipnaf.c) for 
these routines. There are 22 routines here. The other 2 
(desc_inq_addr and get_broadcast) will be in nbnaf_ 
sys.c. inq__max_frag_3ize also requires the addition 
of rpc_b_jnit_Jocal_^^j^vec and rpc_„|^s_ 
local_addr to nbaf_sys.c. 

Add special handling for the adapter # to rpc_nb_init. 

(8) Create desc_Jnq_addr and get_broadcasl, the last 2 
routines in the NAF epv. They go in os22.0/nbnaf_ 
sys.c 

(9) Create twr_nb_lower_llrs_from_sa and 
twr_nb__j^^^^flr5_to.sa. These routines are called by 
tower_Jirs_J"rom_addr and lower__flrs_to_addr in 
the NAF epv. Create twr_nb.c for these functions. 

(10) Add the new protocol towers to the rpc tower_ 

prot__id table in comtwrref.c. 
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(11) Add the NETBIOS protocol sequences to ep.idl so 
RPCD will support NETBIOS. 

(12) Fix protocol dependent stuff in dgsoc.c and dg.h 

(13) Fix protocol dependent stuff_- DG call forwarding 
has an IP sockaddr hardcoded as part of the forwarded 
packet Change this packet in dg.h to allow space for a 
NB sockaddr. Change dglsn.c and dgslsn.c to fix a 
compile problem with the new structure. 

(14) Disable broadcast calls for NETBIOS in dgccall.c 
since current code won't work with NETBIOS. 

(15) Change runtime.lite makefile to support NETBIOS. 

(16) Add new API rpc_jietwork_inq_JocaI jetaddrs to 
?.c. 

3.1 .2 Added/Changed Functions 



abaaf.c 


rpc_nb_iiiit 




addi^alloc 




addr_copy 




addr_s ct_cndpo int 




addr__ing_e[Ki^oint 




addr_flet__iietaddr 




addi_ing_jictaddT 




ing_max_tsdu 




addi_comparc 




ing_max__pth_uD &ag_tpdu 




ing__max_loc_unfrag_tpdu 




dcsc__ing_jictwork 




set_pkt__nodelay (changed to no-op) 




tower flrs__f ro m addr 




towet_Jlors_to_addr 




desc ing , peer addr 




sct_port_ic5triction (changed to no-op) 




get__next__restricted_port (changed to no-op) 




ing_max_&ag_jsize 


nbna£_sys.c 


desc__ing_addr 




get_broadcast 




rpc__nb_init local_addr„vcc 




rpc__nb_is_local_^dr 


twr_nb.c 


twr_nb_lower R rs_f rom_8a 




tw]L_nb_Jower_Jl rs_to_sa 


dgsoc.c 


make code protocol independent 


dgccall.c 


disable datagram broadcast calls 


dglsn.c 


use bcopy with new forwarded packet 


dgslsiLC 


use bcopy with new forwarded packet 



3.1.3 Added/Changed Data 



nbaaf.h 


ipc nb_addr_t 




n'c_c_nb_dgram_max_Ioc_unfTg_tpdu 4088 




ipc_c_nb_dgram^_max_pth_unfig__tpdu 4088 




*pc_c_nb_dgram_jnax_tadu 4088 


com.h 


ipc_c__na£_id_nb 17 




ipc_c_protficg id_ncacn iib_s trcam 




rpc_c_protseg id_ncadg tib_dgram 




ipC_protficg_ncacn_-nb_stream '*ncacn_iib_stieam" 




ipc_protseg_ncacn_jib_dgram "ncadg_nb_dgram" 


comnafh 


add declaration of rpc__nb__init 


dg.h 


make code protocol independent 


twrp.h 


add protocol id for use in NETBIOS tower 


comp.c. 


add 2 entries to protocol sequence ID table 




add 1 entry to the NAF ID table 


comtwrref.c 


add 2 entries to the rpc_towcr_prot_Jd3 tabic 


ep.idl 


add endpoints for NETBIOS protocol sequences to 




RPCD ifspec 


malccfUe.mk 


change nm time, lite makefile to add NETBIOS 



3.2 Security Changes 

Security requires several changes. Security client code 
uses gethostbyname to get the local host addresses and then 
sends this list in a message to the security server, where the 
list is used to compare against he address obtaining from the 



01/20/2004, EAST Version: 1.4.1 



us 6,366,958 Bl 



19 



20 



client binding. This is one of the primary motivalioDS for the 
new RPC API. 

The kcrberos code within security has many protocol 
independent socket calls to send and receive data. TTiis code 
is only used lo contact the security server when RPC fails. 
This code is not being converted to use NETBIOS sockets. 
However, a check is being made to ensure that the failure of 
the AF^INET socket calls in the NETBIOS only environ- 
ment is being handled correctly. 

3.3 Directory Changes 

Directory uses one gethostname( ) call, which must be 
changed, 

3.4 DCED Changes 

The endpoint mapper (fonmeriy RPCD and now inte- 
grated into DCED) uses wcll_-known cndpoints, so DCED 
need to add endpoints for the NETBIOS protocol sequences. 
The changes to ep.idl in RPC are used by DCED. 

3.5 Install/Config Changes 

Install/config also needs to be changed to allow for input 
of NETBIOS host names, specification of the use of NET- 
BIOS protocols, and input of an adapter number to use with 
those protocols. 

4.0 Using Specific Protocol Sequences 
OS/2 DCE supports 4 protocol sequences. 
ncacn_ip_tcp 
ncadg_Jp„udp 
ncacn„unix_stream 
ncacn_nb_strcam 
ncadg_nb_dgram 

The protocol sequences that an RPC server supports 
depends on what protocol sequences the server requests via 
the "use_protseq" APIs. This list of protocol sequences is 
hmited by what is supported by the RPC runtime in the 
session where the server is started. As well, the protocols 
supported by the RPC runtime are limited by the protocols 
that are supported by the current MPTS configuration. 

The protocol sequence actually used when an RPC client 
calls a server must therefore be one that is supported both by 
the RPC server, and by the RPC runtime in the session where 
the RPC chent is started. 

4.1 The RPC SUPPORTED PROTSEQS Environment Vari- 
able 

The RPC_SUPPORTED_PROTSEQS environment 
variable is used to tell the RPC runtime to limit the set of 
supported protocol sequences to those specified by this 
environment variable. The syntax is to list the desired 
protocol sequence strings, separated by colons (not 
semicolons). 

SET RPC_SUPPORTED_PROTSEQS-ncac[i_ip_tcp :ocadg_ 
ip_udp 

Like any other OS/2 environment variable, it can be set in 
CONFIG.SYS where it will be in effect in all sessions, or it 
can be set individually in any session. 

Even if only TCPIP and not NETBIOS is being used, this 
environment variable need not be set, but MPTS must be 
configured for TCPIP and not NETBIOS (or vice versa). 

In general, this environment variable is tjsed to test certain 
protocol sequences in certain sessions. It is not required 
when supporting all protocol sequences, or when all sessions 
will support the same protocol sequence or sequences, since 
this can be limited by MPTS. 

Although the user can override this by resetting the 
RPC_SUPPORTED_J'ROTSEQS environment variable in 
any session, resetting the environment variable is not rec- 
ommended. 
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4.2 HOW RPC PROTOCOL SUPPORT WORKS 

For the RPC runtime to support (allow use of) a particular 
protocol sequence, two things must be true: 

1) The use of the protocol sequence must be allowed, 
either by not setting the RPC_SUPPORTED_ 
PROTSEQS environment variable (the default is all 
protseqs), or by setting it lo the desired protocol 
sequence. 

2) The underlying transport software (MPTS for OS/2) 
must support and be configured for the desired protocol 
sequence. 

When the first call to RPC runtime is made, RPC initial- 
ization is performed, RPC has a list of all possible protocol 
sequences. RPC will first check to see if the RPC_ 
15 SUPPORTEDJROTSEQS environment variable is set. It 
v^dll go through the list and set the "supported" flag for each 
protocol sequence the user has allowed. The default (when 
the environment variable is not set) is to support all protseqs. 
Next RPC initialization will try to open a socket for each 
type, to see if the underlying transport supports the protseq. 

Only those protseqs which were successful are left in the 
List as supported. 

This means the set of supported protseqs can be restricted 
either by setting the environment variable, or by changing 
the MPTS configuration. 

Of course, even if all protocol sequences are supported by 
the RPC runtime, the RPC server can choose to use particu- 
lar protocol sequences through the use of the rpc_server_ 
use_protseq API. 
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5.0 Additional Design Notes 

This section discusses what MPTS should do when BIND 
is called for the NB address family but no NB name is passed 
in. This featurs provides the foDowing functionality: 



(1) have the MPTS GUI prompt for a NB hostname when native NB 
is configured 

^ (2) do name generation for explicit BINDS as well as implicit 
BINDS (when no NB name is specified), 

(3) change the name generation to a 12 byte host name 
appended with a 4 byte incrementing number, 

(4) add an option where the first part (12 bytes) of the host 
name is filled in by MPTS but the last 4 bytes are passed 
by the user. 
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The machine name can be up to 12 bytes long. If it is 
shorter, it will be padded with blanks. If it is longer, it will 
be truncated to 12 bytes, so the result will always be a fixed 
12 byte name. 

The MPTS GUI may bring up a panel to input this name 
when Native NB is configured. The MPTS GUI brings up a 
panel to input this information to build the MPTPADDR 
command when non-native NB is configured. 

Change the BIND call for NB so that MPTS will build a 
NB name using the configured hostname and the snb_narae 
passed as a parameter to BIND. The name generation would 
be as follows: 

snb__name is the 16 byte name field in the sockaddr 
structure for Netbios 

NBNAME is the resulting Netbios Name 

PORT# starts at 1024 

PORTASCn-.PORT# converted to ASCII 

If 1st 12 bytes of snb_nameoO (binary) then 

NBNAME- 12 byte hostname concatenated with 4 byte 
PORTASCII Increment PORT#AND PORTASCII 
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Else (last 4 bytes not 0) (well-known endpoint) 

NBNAMEal2 byte hostname concatenated with last 4 
bytes of snb_name 

Else 

NBNAME=snb_naine 5 
EXAMPLES 

If snb_name- 
"00000000000000000000000000000000"x then (all Os; 
dynamic endpoint) 

NBNAME="mymachincl 1024" (ascii) 
If snb_nameo"00000000000000000000202032303031"x 
then (1st 12 bytes are Os, but last 4 arc not; well-known 
endpoint 

NBNAME-"mymachinel 2001" (ascii) 
If snb_name-"41414141414141414141414141414242"x 
then 91st 12 byles are not 0) 
NBNAME="AAAAAAAAAAAAAABB" (asdi) 
MPTS will build the name with the first 12 bytes being the ^ 
hostname provided with the command. Starting at 1024 
corresponds with the fact that the 0-1023 port range is 
reserved for well-known ports in TCPIR The same name 
generation would be done for connects which cause an 
implicit bind, or any other case where a name must be ^ 
generated. 

One of the preferred implementations of the invention is 
as a set of instructions in a code module resident in the 
random access memory of the endpoint. Until required by 
the computer, the set of instructions may be stored in another ^ 
computer memory, for example, in a hard disk drive, or in 
a removable memory such as an optical disk (for eventual 
use in a CD ROM) or floppy disk (for eventual use in a 
floppy disk drive), or even downloaded via the Intemet. In 
addition, although the various methods described are con- 3^ 
veniently implemented in a general purpose computer selec- 
tively activated or reconfigured by software, one of ordinary 
skill in the art would also recognize that such methods may 
be carried out in hardware, in firmware, or in more special- 
ized apparatus constructed to perform the required method ^ 
steps. 

Further, although the invention has been described in 
terms of a preferred embodiment in a specific network 
environment, those skilled in the art will recognize that the 
invention can be practiced, with modification, in other and 
different network architectures with the spirit and scope of 
the appended claims. Moreover, the inventive naming con- 
version techniques should be useful in any network envi- 
ronment. 

Having thus described my invention, what I claim as new 
and desire to secure by letters patent is set forth in the 
following claims: 

What is claimed is: 

1. In a distributed computing environment wherein client 
machines issue remote procedure calls (RPC's) to server 
machines over a network using a transport mechanism 
specified by an application programming interface (API), a 
first addressing scheme and a first protocol, a method 
comprising the steps of: 

configuring a hostname to represent each server machine gQ 
in the network that supports appflcations associated 
with a second protocol; 
assigning the hostname to a first fixed portion of an 

apphcation address; 
in response to an RPC issued by a client machine, 65 
obtaining an application address from the set of appli- 
cation addresses; and 
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using the application programming interface of the trans- 
port mechanism and the second protocol to execute the 
RPC to a server machine identified by the apphcation 
address. 

2. The method as described in claim 1 wherein the step of 
generating a set of application addresses includes the steps 
of: 

configuring a hostname to represent each server machine 
in the network that supports applications associated 
with the second protocol; and 

assigning the hostname to a first fixed portion of an 
application address. 

3. The method as described in claim 1 wherein an 
application address has a second variable portion. 

4. The method as described in claim 3 wherein the step of 
generating a set of apphcation addresses also includes the 
step of: 

generating a port number for each apphcation associated 
with the second protocol supported on the server 
machine. 

5. The method as described in claim 4 wherein the port 
number is generated on an as-needed basis. 

6. The method as described in claim 2 wherein the 
hostname is configured using a muUiprotocol transport ser- 
vice interface. 

7. The method as described in claim 1 wherein the API of 
the transport mechanism is sockets and the first protocol is 
TCP/IP. 

8. The method as described in claim 7 wherein the second 
protocol is NETBIOS. 

9. The method as described in claim 8 wherein the RPC 
is executed using a NETBIOS connection-oriented protocol 
sequence. 

10. The method as described in claim 8 wherein the RPC 
is executed using a NETBIOS connection-less protocol 
sequence. 

11. In a distributed computing environment wherein chent 
machines normally execute remote procedure cafls (RPC's) 
to server machines over a network using a TCP/IP transport 
mechanism specified by a sockets application programming 
interface (API), a TCP/IP addressing scheme and the TCP/IP 
protocol, the improvement comprising: 

means for configuring a NETBIOS hostname to represent 

each server machine in the network that supports 

NETBIOS applications; 
means for assigning the NETBIOS hostname to a first 

fixed portion of an application address; and 
means responsive to the configuring and assigning means 

for executing remote procedure calls using the sockets 

API and the NETBIOS. 

12. In the distributed computing environment as described 
in claim 11 wherein the mapping means includes: 

means for configuring a NETBIOS hostname to represent 
each server machine in the network that suppports 
NETBOIS applications; and 

means for assigning the NETBIOS hostname to a first 
fixed portion of an application address. 

13. In the distributed computing environment as describe 
in claim 11 wherein the mapping means further includes: 

means for generating a port number for each NETBIOS 
apphcation supported on the server machine; and 

means for assigning the port number to a second variable 
portion of the application address. 

14. In the distributed computing environment as described 
in claim 13 wherein the fixed first portion of the application 
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address is 12 bytes and the second variable portion of the 
application address is 4 bytes. 

15. In the distributed computing environment as described 
in claim 13 Wherein the means for generating a port number 
is a multiprotocol networking service. 

16. A computer connectablc into a distributed computing 
environment wherein client machines normally execute 
remote procedure calls (RPC's) to server machines over a 
network using a TCP/IP transport mechanism specified by a 
sockets application programming interface (API), a TCP/IP 
addressing scheme and the TCP/IP protocol, comprising: 

a processor; 

an operating system; and 
a multiprotocol transport service (MPTS); and 
NETBIOS protocol support means for configuring and 
managing NETBIOS application addresses to enable 
execution of RPC's using the sockets API and the 
NETBIOS protocol. 

17. The computer as described in claim 16 wherein the 
NETBIOS protocol support means includes: 

means for configuring a NETBIOS hostname to represent 
each server machine in the network that supports 
NETBIOS applications; and 

means for assigning the NETBIOS hostname to a first 
fixed portion of an application address. 
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18. The computer as described in claim 17 wherein the 
NETBIOS protocol support means further includes: 

means for generating a port number for each NETBIOS 
application supported on the server machine; and 

means for assigning the port number to a second variable 
portion of the application address. 

19. The computer as described in claim 16 wherein the 
multiprotocol network transport service (MPTS) includes 

10 means for automatically generating NETBIOS names. 

20. A computer program product for use in a computer 
having a processor, a memory and means for connecting the 
computer into a distributed computing environment wherein 
client machines normally execute remote procedure calls 

15 (RPC's) to server machines over a network using a TCP/IP 
transport mechanism specified by a sockets application 
programming interface (API), a TCP/IP addressing scheme 
and the TCP/IP protocol, the computer program product 
comprising: 

20 means for configuring NETBIOS application names to 
conform to the TCP/IP addressing scheme; and 
means responsive to the configuring means for executing 
remote procedure calls using the sockets API and the 
NETBIOS protocol. 

25 

» « * * ♦ 
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portion of an application address; and means responsive to the configuring and 
assigning means for executing remote procedure calls using the sockets API 
and the NETBIOS" and insert therefor 

" means for mapping NETBIOS application names to conform to the TCP/IP 
addressing scheme; and means responsive to the mapping means for executing 
remote procedure calls using the sockets API and the NETBIOS protocol 
Line 56, "NETBOIS" should read - NETBIOS ~. 
Line 60, "claim 11" should read claim 12 ~. 
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